U.S.  DEPARTMENT  OF  COMMERCE 
National  Institute  of  Standards  and  Technology 


mr 

FUBLiCATlOMS 


piequiremenis  i 
an  Application 
Protocol 
Development 
Environment 


NISTIR  5197 


National  PDES  Testbed 


Report  Series 


NATL  INST  or  STAND  Jt  TECH  SIC 


Allison  Barnard  Feeney 
NATIONAL  Nowland  Clark 


TESTBED  TM 


-iie — 
100 
.056 
//5197 
1993 


NISTIR5197 


National  PDES  Testbed 
Report  Series 


Sponsored  by: 


U.S.  Department  of  Defense 

CALS  Evaluation  and  NATION^  -n  • g ^ 

Integration  Office  ^ 

1 ivequiremeius  lur 

1^  an  Application 
Protocol 

Development 

Environment 

Allison  Barnard  Feeney 

Stephen  Nowland  Clark 

James  E.  Fowler 

The  Pentagon 

Washington,  DC  20301-8000 

U.S.  Department  of  Commerce 

Ronald  Brown, 

Secretary  of  Commerce 

Technology  Administration 

John  W.  Lyons,  Acting 

Under  Secretary  for  Technology 

National  Institute  of 

Standards  and  Technology 

Raymond  Kammer,  Acting 
Director 


May  27, 1993 


Table  of  Contents 


1 Introduction 1 

1 . 1 Motivation 2 

1.2  AP  Development  Process 2 

1.2.1  AP  Project  Definition 2 

1.2.2  AP  Information  Requirements 3 

1.2.3  AP  Interpretation 3 

1.2.4  Complete  AP 4 

1.3  Approach  to  APDE  Development 4 

2 Technical  Requirements 5 

2.1  AP  Project  Definition  Requirements 5 

2.2  AP  Information  Requirements 6 

2.3  AP  Interpretation  Requirements 7 

2.4  Complete  AP  Requirements 8 

2.5  General 9 

3 Conclusion 10 

Appendix  A:  References 11 


Page  iii 


Disclaimer 


No  approval  or  endorsement  of  any  commercial  product  by  the  National  Institute  of 
Standards  and  Technology  is  intended  or  implied. 

This  publication  was  prepared  by  United  States  Government  employees  as  part  of  their 
official  duties  and  is,  therefore,  a work  of  the  U.S.  Government  and  not  subject  to 
copyright. 

Acknowledgement 

The  National  PDES  Testbed  project  is  funded  by  the  Computer-aided  Acquisition  and 
Logistic  Support  (CALS)  Office  of  the  U.S.  Department  of  Defense. 


Page  iv 


Requirements  for  an  Application 
Protocol  Development  Environment 


Allison  Barnard  Feeney 
Stephen  Nowland  Clark 
James  E.  Fowler 


Introduction 

The  emerging  international  standard  for  the  exchange  of  product  model  data  (STEP*) 

'2 

comprises  several  distinct  series  of  Parts  . “Implementation  Specifications”  provide 
descriptions  of  mechanisms  for  the  actual  exchange  of  STEP  data  (e.g..  Clear  Text 
Encoding  of  the  Exchange  File  [3]).  “Descriptive  Methods”  provide  techniques  for 
specifying  STEP  (e.g..  Data  Specification  Language  EXPRESS  [2] (.“Integrated 
Resources”  are  considered  the  basic  building  blocks  of  STEP;  these  Parts  provide 
information  models  describing  generic  constructs  which  are  useful  in  a wide  variety  of 
product  applications  (e.g..  Geometry  [4]).  “Application  Protocols”  are  the  Parts  of 
STEP  which  combine  components  of  Integrated  Resources,  select  implementation 
mechanisms,  and  use  the  established  Descriptive  Methods  to  specify  what  product  data 
is  to  be  exchanged  and  what  the  meaning  of  that  data  is  in  a particular  industrial  context 
(e.g..  Associative  Draughting  [5]).  In  essence.  Application  Protocols  (APs)  are  the  Parts 

of  STEP  which  are  implementable.  Thus  it  can  be  expected  that  CAx  vendors  will 
provide  mechanisms  in  their  products  which  will  facilitate  data  exchange  according  to 
particular  APs.  A thorough  introduction  to  STEP  and  its  constituent  specifications  can 
be  found  in  “Overview  and  Fundamental  Principles”  [1]. 

The  National  PDFS  Testbed  project  at  the  National  Institute  of  Standards  and 
Technology  is  focussed  on  the  development  and  implementation  of  STEP.  Principal 
funding  for  the  National  PDFS  Testbed  project  comes  from  the  Department  of  Defense 
Computer-aided  Acquisition  and  Logistic  Support  (CALS)  office.  There  are  several 
sub-projects  within  the  National  PDFS  Testbed;  among  these  is  the  effort  to  establish 
an  Application  Protocol  Development  Environment. 


1.  STEP  is  being  standardized  under  the  auspices  of  the  International  Organization  for  Standardization  (ISO) 
Technical  Committee  184  (TC184)  Subcommittee  4 (SC4).  The  tena  PDES  (FYoduct  Data  ExcLmge  using 
STEP)  refers  to  the  United  States  contributing  effort  to  this  standardization  process. 

2.  STEP  will  be  released  as  a collection  of  specifications;  each  individual  specification  is  known  as  a “Ptm” 
of  STEP. 

3.  The  term  “CAx”  refers  to  any  type  of  engineering  or  manufacturing  software  application  system,  e.g., 
Computer-Aided  Design  (CAD),  Computer-Aided  Process  Planning  (CAPP),  etc. 
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This  report  documents  the  requirements  for  an  Application  Protocol  Development 
Environment  (APDE).  These  requirements  provide  fundamental  guidance  as  to  what 
software  capabilities  would  benefit  Application  Protocol  developers  in  their  efforts  to 
specify  APs.  The  requirements  described  in  this  report  are  derived  from  the  experiences 
of  current  AP  developers. 

1.1  Motivation 

AP  development  is  a time-consuming,  labor-intensive,  and  thereby  expensive  process. 
The  process  for  developing  APs  is  defined  by  ISO/TC184/SC4  and  is  documented  in 
the  “Guidelines  for  AP  Development”  [ 10],  A scheduling  estimation  from  the  author  of 
that  document  states  that  6294  man-hours  of  effort  over  more  than  1.5  years  are 
required  for  development  of  a single  AP.  STEP  currently  has  2 APs  which  are  being 
readied  for  release  as  international  standards  while  at  the  same  time  more  than  20  APs 
are  either  in  development  or  in  the  planning  stages.  The  total  number  of  APs  which  will 
eventually  be  defined  in  STEP  can  not  be  accurately  predicted  at  this  time;  however  the 
number  could  easily  reach  into  the  hundreds. 

Given  the  cost  of  developing  APs  and  the  fundamental  relationship  between  the 
standardization  of  APs  and  the  usefulness  of  STEP,  the  National  PDES  Testbed  project 
has  initiated  an  effort  to  establish  an  Application  Protocol  Development  Environment. 
The  mission  of  the  effort  is  to  put  into  place  an  integrated  suite  of  software  tools  which 
together  improve  the  productivity  of  AP  developers  and  facilitate  the  specification  of 
high  quality  APs. 

1.2  AP  Development  Process 

The  purpose  of  this  section  is  to  give  an  overview  of  the  AP  development  process.  For 
complete  details  of  the  process  the  reader  is  urged  to  consult  the  Guidelines  document 
[10].  It  is  important  to  note  that  no  software  tools  are  currently  available  which  are 
specifically  intended  to  facilitate  the  AP  development  process.  AP  developers  currently 
use  an  ad  hoc  collection  of  document  processing  software,  information  modeling 
software,  and  virtually  anything  else  available  which  may  make  these  tasks  easier. 

1.2.1  AP  Project  Definition 

An  AP  project  is  initiated  by  documenting  an  industry  need  for  the  AP,  i.e.,  establishing 
the  requirement  for  a particular  AP  in  STEP.  A high-level  statement  of  scope  is  agreed 
upon  (and  updated  as  the  AP  becomes  better  defined).  In  order  to  further  document  the 
industry  need,  the  AP  developers  produce  an  Application  Activity  Model  (AAM) 
which  specifies  the  processes  that  use  and  produce  product  data  in  the  context  of  a 
specific  application.  The  AAM  is  documented  using  IDEFO  [6]  methodology.  Once  a 
comprehensive  AAM  is  developed,  each  element  of  the  AAM  is  examined  and  a 
determination  is  made  whether  the  element  is  in  or  out  of  scope,  based  on  the  intended 
use  of  the  AP.  The  scope  statement,  the  completed  AAM,  and  a Candidate  AP 
Summary  sheet  are  submitted  for  approval  as  an  AP  project. 
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Once  the  AP  project  is  approved,  the  scope,  requirements  and  A AM  are  evaluated  by 
experts  in  the  application  area  who  were  not  involved  in  the  initial  modeling  effort. 
These  experts  should  reflect  the  breadth  and  depth  of  the  application  scope.  The  AAM 
is  modified  to  ensure  that  it  meets  industry  needs,  is  viable,  and  accurately  reflects  the 
desired  .scope.  The  results  of  the  industry  review  are  documented  in  a separate 
document,  the  AP  Validation  Report. 

1.2.2  AP  Information  Requirements 

After  the  AP  scope  has  been  defined  and  evaluated,  the  information  requirements  of  the 
AP  are  defined  through  the  development  of  an  Application  Reference  Model  (ARM). 
The  ARM  may  be  documented  in  one  of  three  data  modeling  languages  (EXPRESS  |21, 
IDEE  IX  [7]  or  NIAM  [9]).  The  model  diagrams  are  a required  part  of  the  AP,  but 
information  requirements  are  normatively  described  in  text.  Each  element  in  the  ARM 
diagrams  is  defined  as  an  Application  Object  in  the  AP.  Each  relationship  between 
elements  in  the  ARM  diagram  is  documented  as  an  Application  Construct.  The 
concepts  in  the  ARM  are  organized  into  Units  of  Functionality  (UoF).  A UoF  is  a 
grouping  of  constructs  which  reflect  one  or  more  distinct  concepts  within  the  ARM, 
possibly  corresponding  to  an  application  process.  The  UoFs  are  potentially  useful  for 
evaluating  areas  of  commonality  between  APs. 

The  ARM  must  be  evaluated  by  industry  experts  as  was  the  AAM.  The  objective  of 
ARM  validation  is  to  provide  a high  degree  of  confidence  that  the  model  supports 
industry  practices  correctly  and  robustly.  It  is  impractical  to  conduct  a comprehensive 
review  of  the  ARM  due  to  its  complexity.  ARM  validation  is  done  with  the  use  of 
representative  test  pieces  and  usage  scenarios.  The  model  may  be  validated  by  several 
methods.  One  method  is  to  build  a prototype  database  that  replicates  the  structure  of  the 
ARM,  another  method  is  to  perform  “paper  populations”  of  the  structure  and 
requirements.  The  method  used  to  perform  ARM  validation  is  documented  in  the  AP 
Validation  Report. 

1.2.3  AP  Interpretation 

The  Application  Interpreted  Model  (AIM)  is  developed  by  interpreting  elements  from 
the  STEP  Integrated  Resource  Parts  to  the  information  requirements  described  in  the 
ARM.  This  process  requires  the  cooperation  of  those  who  developed  the  model  and 
those  who  have  extensive  knowledge  of  the  Integrated  Resources.  Interpretation  is 
typically  carried  out  in  a workshop-style  meeting.  Detailed  notes  from  the 
interpretation  are  compiled  into  an  Interpretation  Report  that  becomes  part  of  the  AP 
Validation  Report.  Another  output  of  the  Interpretation  workshop  is  a mapping  table 
that  shows  the  correspondence  between  elements  of  the  ARM  and  those  from  the  other 
Parts  of  STEP.  The  AIM  is  documented  by  an  information  model  known  as  a Short 
Listing.  The  Short  Listing  consists  of  references  to  Integrated  Resource  elements  and 
the  speciahzations  of  those  elements  for  the  AP,  e.g.,  the  rules  that  further  constrain 
Integrated  Resource  elements.  An  expanded  form  of  the  Short  Listing  is  also  required 
in  the  AP;  it  is  known  as  the  Annotated  Listing.  The  Annotated  Listing  includes  the 
complete  documentation  of  the  AIM,  along  with  definitions  of  all  of  the  information 
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elements  specified  by  the  AIM.  During  the  development  of  the  Short  and  Annotated 
Listings,  the  AP  developers  must  also  develop  a high-level  graphical  model  of  the 
information  using  the  diagrammatic  form  of  EXPRESS  (EXPRESS-G*). 

Finally,  as  with  the  ARM,  validation  of  the  AIM  must  be  performed  and  documented 
in  the  AP  Validation  Report.  AP  usage  information  formulated  for  the  validation 
process  may  also  be  provided  as  an  informative  portion  of  the  AP  document  itself. 

1.2.4  Complete  AP 

Once  the  AP  developers  have  completed  the  documentation  and  validation  of  the  AIM, 
the  remainder  of  the  AP  development  work  involves  defining  implementation  and 
conformance  requirements.  This  ensures  that  there  are  metrics  available  against  which 
vendor  implementations  of  the  AP  can  be  tested  for  conformance.  The  information 
requirements  and  assertions  defined  in  the  ARM  and  all  characteristics  defined  in  the 
AIM  are  the  starting  points  for  the  development  of  such  conformance  requirements. 
Test  Groups  are  defined  from  the  structure  of  the  ARM  and  Test  Purposes  are  defined 
for  all  constructs  of  the  AIM.  Review  and  evaluation  of  the  AP’s  Conformance 
Requirements  and  Test  Purposes  is  performed  by  application  experts  and  AP  methods 
experts.  The  results  of  this  evaluation  are  included  in  the  AP  Validation  Report. 

AP  developers  are  also  responsible  for  compiling  all  of  the  requisite  components  of  the 
AP  specification  into  a document  according  to  established  style  guidelines  [11].  At 
several  stages  of  AP  completion  the  document  is  submitted  to  various  committees  and 
representatives  of  voting  members  (countries)  in  ISO  for  review  and  comment. 
Maintaining  logs  of  issues  raised  against  the  AP  and  responding  to  those  issues  is 
another  aspect  of  the  AP  development  process. 

1.3  Approach  to  APDE  Development 

The  National  PDES  Testbed  project  to  establish  an  APDE  will  be  a multi-year  effort. 
The  first  phase  of  the  approach  is  to  identify  requirements  of  AP  developers  pertaining 
to  software  support.  The  project  will  later  specify  the  functionality  of  an  APDE  which 
satisfies  these  requirements.  The  actual  implementation  of  the  specified  functionality 
will  take  place  over  a period  of  several  years.  The  implementation  strategy  will  take 
into  account  a prioritization  of  the  requirements  based  on  immediate  benefit  to  AP 
developers  and  the  resources  available  to  satisfy  those  requirements.  Furthermore,  it  is 
likely  that  the  requirements  themselves  will  change  over  time,  particularly  given  that 
the  process  for  AP  development  is  itself  subject  to  refinement.  Thus  the  requirements 
described  in  this  report  are  considered  the  initial  set  from  which  to  begin,  but  probably 
not  the  complete  set  of  requirements. 

The  APDE  is  currently  envisioned  to  be  a collection  of  distinct  software  tools  which  are 
tied  together  through  an  AP  Information  Base  (InfoBase).  The  software  tools  would 
serve  to  support  the  various  processes  which  AP  developers  must  execute.  Information 
resulting  from  the  execution  of  any  one  process  would  be  available  to  any  of  the  other 
processes  through  the  AP  InfoBase.  The  InfoBase  will  thus  have  capabilities  to  both 


1.  EXPRESS-G  is  a graphical  subset  of  EXPRESS.  See  Annex  D of  [2]  for  a description. 
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Store  and  retrieve  intorination  needed  by  AP  developers.  Such  information  may  include 
STEP  Integrated  Resources,  AP  components,  and  even  AP  development  methodology 
instructions. 

2 Technical  Requirements 

This  section  identifies  the  technical  requirements  for  the  APDE.  Most  requirements  are 
categorized  according  to  the  stages  of  AP  development  to  which  they  apply.  The  last 
category  (General)  captures  requirements  which  are  applicable  to  the  environment  as  a 
whole.  There  is  no  special  ordering  to  the  requirements  within  each  category.  The 
reader  is  reminded  that  the  purpose  of  this  report  is  to  identify  requirements;  describing 
how  the  requirements  will  be  addressed  is  beyond  the  scope  of  this  report. 

2.1  AP  Project  Definition  Requirements 

See  .section  1.2. 1 for  a description  of  the  activities  involved  in  this  aspect  of  AP 
development. 

Requirement  2.1.A: 

Provide  a structured  approach  for  gathering  the  requirements  used  to  establish  the 
need  for  a particular  AP. 

Requirement  2.1.B: 

Document  activity  requirements  in  a standard  format. 

Requirement  2.1.C: 

Evaluate  an  AAM  decomposition  and  document  the  results  of  the  evaluation. 

Requirement  2.1. D: 

Maintain  proper  relationships  between  IDEFO  model  constructs  in  a graphical 
IDEFO  modeling  tool. 

Requirement  2.1.E; 

Allow  the  user  to  control  levels  of  IDEE  rule  enforcement  in  a graphical  IDEFO 
modeling  tool. 

Requirement  2.1.F: 

Allow  transfer  of  information  resulting  from  AAM  definition  to  other  software 
tools  supporting  other  processes. 

Requirement  2.1.G: 

Automatically  produce  a template  for  the  AAM  glossary  from  the  AAM. 

Requirement  2.1.H: 

Evaluate  the  correspondence  between  the  AAM  and  the  AP  Scope  and 
Requirements. 
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Requirement  2.1.1: 

Maintain  version  control  between  the  representations  of  AP  Scope,  AP 
Requirements,  and  AAM. 

2.2  AP  Information  Requirements 

See  section  1 .2.2  for  a description  of  the  activities  involved  in  this  aspect  of  AP 
development. 

Requirement  2.2. A: 

Link  information  models  to  documentation  of  model  components. 

Requirement  2.2. B: 

Provide  for  identification  of  Units  of  Functionality  and  connection  to  the 
documentation  of  same. 

Requirement  2.2. C: 

Translate  among  information  modeling  languages,  e.g.,  IDEFIX  to  EXPRESS, 
NIAM  to  EXPRESS. 

Requirement  2.2. D: 

Allow  printing  of  graphical  information  models  as  “wall  charts”  with  automatically 
generated  cross-page  references  between  model  elements. 

Requirement  2.2.E: 

Check  information  models  to  user-specified  levels,  e.g.,  consistency,  syntax, 
constraints. 

Requirement  2.2. F: 

Support  information  model  development  by  work-groups,  i.e.,  “groupware”. 

Requirement  2.2.G; 

Maintain  version  control  between  results  of  upstream  processes,  representations  of 
ARM  components,  and  documentation  of  the  ARM. 

Requirement  2.2.H: 

Allow  on-line  browsing  of  other  APs’  components. 

Requirement  2.2.1; 

Support  ARM  validation. 

Requirement  2.2..T: 

Manage  changes  between  information  requirements,  AP  definition,  and 
documentation. 
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2.3  AP  Interpretation  Requirements 

See  section  1.2.3  for  a description  of  the  activities  involved  in  this  aspect  of  AP 
development. 

Requirement  2.3.A: 

Provide  on-line  access  to  to  STEP  specifications,  e.g..  Integrated  Resource  Parts, 
APs,  etc. 

Requirement  2.3. B: 

Link  information  models  in  STEP  Integrated  Resource  Parts  with  the 
documentation  of  the  information  models. 

Requirement  2.3.C: 

Allow  queries  against  Integrated  Resources  and  against  the  AIM  as  it  is  being 
developed,  e.g.,  determining  what  entities  are  implicitly  required  when  a specific 
entity  is  chosen;  determining  whether  a specific  entity  has  already  been  chosen,  etc. 

Requirement  2.3.D: 

Allow  creation  of  constraints  for  an  EXPRESS  information  model  based  on  a 
family  of  specified  constraint  templates. 

Requirement  2.3.E: 

Provide  on-line  access  to  guidelines  for  AP  interpretation. 

Requirement  2.3.F: 

Structure  the  software  supporting  the  interpretation  process  so  that  guidelines  for 
AP  interpretation  are  enforced. 

Requirement  2.3.G; 

Automatically  determine  the  mappings  between  ARM  components  and  STEP 
Integrated  Resources  document  the  correspondences. 

Requirement  2.3.H: 

Provide  language-sensitive  editing  of  EXPRESS  and  syntax/semantic  checking  as 
well. 

Requirement  2.3.1: 

Allow  creation  of  the  Mapping  Table  based  on  a template  for  the  Mapping  Table. 

Requirement  2.3..T: 

Generate  the  reference  paths  of  the  AIM  against  the  Integrated  Resources  and  the 
documentation  of  this  information. 

Requirement  2.3.K: 

Verify  that  all  ARM  components  are  interpreted. 

Requirement  2.3.L: 

Generate  the  AIM  Annotated  Listing  from  the  AIM  Short  Listing;  the  Annotated 
Listing  produced  should  reproduce  all  textual  descriptions  implicitly  associated 
with  the  EXPRESS  entities  from  the  Integrated  Resources. 
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Requirement  2.3.1V1: 

Verify  the  correctness  of  an  AIM  Annotated  Listing  given  an  AIM  Short  Listing. 

Requirement  2.3.N: 

Support  the  storage  and  retrieval  of  AICs;  allow  for  the  determination/examination 
of  different  usages  of  a specified  AIC. 

Requirement  2.3.0: 

Automatically  generate  EXPRESS-G  diagrams  from  EXPRESS. 

Requirement  2.3.P: 

Allow  graphical  creation  and  editing  of  EXPRESS-G  models. 

Requirement  2.3.0: 

Provide  translations  from  the  representation  of  an  EXPRESS-G  model  into 

PostScript^  and  other  formats  which  can  be  imported  into  document  processing 
software. 

Requirement  2.3.R; 

Allow  for  creation  and  querying  of  STEP  data  corresponding  to  the  AIM. 

Requirement  2.3.S: 

Generate  a STEP  Exchange  File  template  containing  each  instance  possibility  in  the 
AIM. 

Requirement  2.3.T: 

Support  AIM  validation. 

2.4  Complete  AP  Requirements 

See  section  1.2.4  for  a description  of  the  activities  involved  in  this  aspect  of  AP 
development. 

Requirement  2.4.A: 

Provide  templates  which  conform  to  ISO  style  guidelines  for  use  in  development  of 
AP  document  components.  Changes  to  ISO  style  guidelines  should  be  reflected  in 
such  templates  and  automatically  propogated  into  draft  documents. 

Requirement  2.4.B: 

Verify  (English)  grammar  usage  and  style  in  AP  document  components  according 
to  ISO  guidelines. 

Requirement  2.4.C: 

Track  AP  document  component  status  by  identifying  which  clauses  are  complete 
and  which  are  incomplete. 


1.  PostScript  is  a registered  trademark  of  Adobe  Systems  Incorporated. 
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Requirement  2.4.1): 

Automatically  merge  templates,  boilerplate  text,  information  models,  and  other  AP 
components  into  an  AP  document. 

2.5  General 

This  section  describes  requirements  which  are  applicable  to  several  or  all  AP 
development  processes. 

Requirement  2.5.A; 

Provide  translation  between  LaTeX  and  WordPerfecr  (both  directions). 

Requirement  2.5.B; 

Provide  simultaneous  viewing  of  multiple  pages  of  a STEP  specification. 

Requirement  2.5.C; 

Search  for  issues  based  on  keywords. 

Requirement  2.5. D: 

Provide  a uniform  format  for  issues,  e.g.,  date,  author,  description,  action  taken, 
tracking  status,  date  resolved,  resources  allocated. 

Requirement  2.5.E: 

Connect  issue  descriptions  to  any  specified  target,  e.g.,  document  text,  entity 
definition,  rule,  etc. 

Requirement  2.5.F; 

Establish  version  control  mechanisms  between  particular  issues  and  particular 
versions  of  STEP  specifications. 

Requirement  2.5.G; 

Distribute  issue  descriptions  and  resolutions  to  all  specified  stake-holders. 

Requirement  2.5. H: 

Establish  version  control  on/between  components  of  AP  documents. 

Requirement  2,5.1; 

Provide  all  necessary  information  (e.g.,  AP  development  guidelines,  ISO  style 
guidelines,  STEP  Parts,  etc.)  in  one  place. 


1.  LaTeX  is  a freely  available  document  processing  system  [8]. 

2.  WordPerfect  is  a registered  trademark  of  WordPerfect  Corporation. 
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3 Conclusion 

The  technical  requirements  presented  in  this  report  constitute  a starting  point  for 
specification  of  an  Application  Protocol  Development  Environment.  This  report  only 
seeks  to  identify  an  initial  set  of  requirements.  Care  has  been  taken  to  describe  what  is 
needed  without  formulating  a specific  technical  solution.  Most,  if  not  all  of  the 
requirements  can  be  addressed  by  a variety  of  solutions.  Some  solutions  are  relatively 
simple  to  address  but  most  are  not.  In  conveying  the  requirements  to  the  authors,  AP 
developers  have  frequently  indicated  what  solutions  are  more  preferable  than  others. 
The  APDE  project  will  use  that  information  to  balance  potential  solutions  with  the 
ability  to  deliver  such  solutions. 

It  should  be  noted  that  not  all  aspects  of  AP  development  have  yielded  requirements. 
For  example,  delivery  of  conformance  requirements  and  test  criteria  are  necessary 
tasks,  yet  there  are  no  requirements  for  tools  or  techniques  to  assist  with  these  tasks. 
Unfortunately,  the  lack  of  requirements  is  probably  not  due  to  the  simplicity  of  the 
activiity  or  the  availability  of  existing  tools.  Instead  the  absence  of  requirements  is 
attributed  to  a lack  of  experience  on  those  tasks.  When  all  aspects  of  AP  development 
are  exercised,  it  can  be  expected  that  there  will  be  additional  requirements  for  the 
APDE. 

Finally,  the  authors  express  their  gratitude  for  the  cooperation  of  AP  developers  as  a 
source  of  requirements.  Specifically,  the  authors  wish  to  thank  Diane  Allen  (Northrop), 
Rick  Bsharah  (Rockwell  International),  Shaw  Feng  (NIST),  Julian  Fowler 
(CADDETC),  Mitchell  Gilbert  (Grumman  Data  Systems),  Keith  Hunten  (General 
Dynamics),  Larry  McKee  (IBM),  Constantine  Orogo  (Concurrent  Technologies  Corp.), 
Larry  Parker  (General  Motors/Hughes),  Linas  Polikaitis  (Northrop),  Kent  Reed 
(NIST),  Steve  Ryan  (General  Electric),  Mike  Strub  (General  Motors/Electronic  Data 
Systems),  and  Glen  Ziolko  (Vought). 
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